There s a lot of things I d like to blog about. The last version of OpenStack, the OpenStack Liberty design summit, Kilo in the official jessie-backports repositories, etc. Maybe the most interesting part of this blog post is the last bit at the end, about a major change in the packaging workflow for OpenStack in Debian. Please read on OpenStack release names reminder
Just a reminder to make it easier for the average Debian reader who may know Debian well, but not OpenStack. OpenStack 2014.1, is Icehouse, and is the version in Jessie. 2014.2 is Juno and was released right before the freeze of Jessie. 2015.1.0 is what has been released just right after jessie, on the 30th of April. Liberty, which probably will be called 12 (as this will be the 12th release of OpenStack), and not 2015.2 (this has been discussed in Vancouver), will be released in about 5 months form now. The last summit, in Vancouver, BC, Canada, was the Liberty summit, as the OpenStack conventions are always named after the next release (since we are discussing what we will be doing during the next development cycle). OpenStack 2015.1.0, aka Kilo, release in Debian
5 days after the release of Jessie, OpenStack 2015.1.0, aka Kilo, was released. Since I couldn t upload to unstable during the freeze, I was holding a lot of packages, and when I did upload them, there was about 20 packages of mine in the FTP master s NEW queue. Though, since the DSA want to use OpenStack for the Debian infrastructure, the 20 packages were fast track into Sid, thanks to the work of Paultag (thanks man!). OpenStack Kilo in the official Jessie backports
Previously, I was only uploading OpenStack packages to Debian unstable, and maintaining a non-official Debian repositories for backports to Debian stable. However, for multiple reasons, this wasn t satisfying. Then, after packages migrated to Stretch, I started to upload to Debian backports. And right before the summit, almost everything went in. Only python-pysaml2 was missing (as I discovered too late that version 2.0.0 breaks Keystone which needs version 2.4.0). In fact, the last bits of the Kilo release reached jessie-backports in the middle of the OpenStack Liberty summit. Removal of the Debian install-guide from the official site
As there was not enough efforts working on the documentation, unfortunately, the link to the Debian install-guide has been removed from docs.openstack.org. IMO, this is mostly due to a bad communication between myself and the doc team, and also because one person who promised to work on the Debian side of the install-guide failed to warn everyone that he finally couldn t (as his managers assigned him to something else). I hope this will soon be reverted. During the Vancouver summit, I had the opportunity to discuss with the doc team about re-inclusion of the Debian install-guide. Unfortunately, as they are moving away from the XML source format to a more standard RST-based system, the current documentation is frozen, so it seems more realistic to hold on until all of the install-guide is switched to RST. OpenStack Debian image listed on apps.openstack.org
There s a new area on the openstack.org where images and apps for OpenStack are listed. Under the glance image tab, you will see that both the Jessie and the weekly testing image are listed. There s also a nice, easily identifiable Debian logo to link to these images. Also, as there are trademark problems with the Ubuntu images which makes them harder to redistribute, the Murano project (which is shipping a system to automatically install apps that to installed within a few clicks on an OpenStack cloud) decided to switch to Debian for their base image. Debian listed in the OpenStack market place
On the openstack.org site, there s a section called Marketplace. In there, vendors supporting OpenStack are listed. To get there, a vendor needs to 1/ have a defined set of OpenStack project supported by the distribution (Debian already has a way more than the required set), 2/ sign some kind of agreement with the OpenStack foundation, and 3/ pay some sponsoring money. During the summit, I discussed this with Jonathan Bryce, from the OpenStack foundation, and he agreed that Debian would not have to pay for this (since we aren t a big company with big money). I have put Jonathan and Neil (our Debian Project Leader) in touch so that signing the document may happen, though since we were all busy with the summit, I do not expect Jonathan to send the documents right away. Hopefully, this will be fixed before the end of this month of May 2015. Debian (and Ubuntu) packages collaboratively maintained upstream
Since about forever (forever is 5 years in the OpenStack world ), I pushed for more collaboration on OpenStack packaging between Debian package maintainers and Canonical. However, for some reasons which I do not wish to expand on in this blog post, it has been socially hard to do so. Also, Canonical always used BZR, which wasn t to the tastes of everyone. But during the Liberty summit, some very good things happened. First of all, Launchpad is now able to support Git (it s been a few weeks it does in fact). Even though it will take a bit of time before the Canonical server team switches to it, we can consider that this problem is already out of the way. Then it looks like Canonical are now more open than before for collaboration with Debian on the OpenStack packaging. Note that we actually did some work together already, but now we both would like a full alignment of *all* of our packages. I have discussed this with James Page, who is the head of Canonical s server team. We will first start to do so on the dependencies: this includes all of the python-*client libraries, but also all of python-oslo.* (the Oslo libs are use by all of the projects and are kind of unifying the project), plus all the third party dependencies the project relies on. James already pushed new versions of some Oslo libraries to Experimental (in order to not overwrite Kilo), which are adding transition packages needed for Ubuntu. We wont need those in Debian, but we want to welcome them to keep the same source packages. We will then later try to merge the core projects if we can. Unfortunately, since the packaging of the core projects (ie: Nova, Neutron, Cinder, Glance, etc.) was forked, merging probably will be a bit painful. We will have to make some decisions on how this happen. I am however confident that it will be done during the Liberty release cycle. Move of the packaging to upstream Gerrit
A few weeks after the summit, I wrote a proposal to upstream OpenStack dev list, with as subject: Adding packaging as an OpenStack project . What it means is that I have proposed to have Debian/Ubuntu packaging to happen in upstream infrastructure, using Gerrit, and building packages using upstream cloud. We will add all the tests we can, like building with unit tests, lintian, piuparts, adequate, but also maybe a full installation of the packages with functional tests. My proposal is here: http://lists.openstack.org/pipermail/openstack-dev/2015-May/064848.html As everything, this translates into a Gerrit review process: https://review.openstack.org/#/c/185187/ As you can read in the above thread, Fedora/RDO people, which have used a Gerrit work-flow for a long time already, also would like to join. But it looks like we ll be doing 2 teams: one for RPMs and one for debs. The proposal is currently under review by the OpenStack technical committee, which will accept (or not) if the packaging project can be fully considered as an OpenStack project. I expect a final answer next Tuesday. Note that if they deny, we can still use the stackforge namespace instead, their decision is just about the TC blessing the project as being OpenStack or not. What s very nice about this, is that not only we will have a better collaboration between Debian & Ubuntu, better automated testing and Q/A, this also opens contributions to potentially anyone. Especially, we welcome operation people, those who are doing actual big deployments. Sure, it was possible before, but I often had the feedback that many were scared to break anything when trying to contribute. Thanks to the CI/CD form upstream infra, and the Gerrit peer review process, it wont be a problem anymore. So we do expect operation people to contribute more. I will also push more upstream packaging within Mirantis, so that MOS (Mirantis OpenStack) aligns fully with Debian & Ubuntu as well. Another good thing, is that it will be easier for the puppet team to support Debian (they historically were more Ubuntu oriented), and it s going to be super easy for them to request for packaging fixes. I hope we will be able to work hand-to-hand with them, adding puppet deployment checks in the packaging repo, and packaged deployments within the puppet Gerrit review process.

I implemented <? support (including <?php ) script embedding support for *.inc in MirWebseite today; the specific syntax was explicitely requested by Natureshadow. Ugh. My own hacking activities are progressing, even if slowly. I do some other interesting, funny, social, beneficial, etc. stuff in between, though. I ll even have to get some of my DD buddies to sponsor me some QA uploads of packages I formerly maintained, whereever changes are queued up such as better old-format repo compatibility in cvs(GNU) Though some of the stuff I do at work is currently done only there sorry. Also: prepare to be fully enlightened about just what evil (nice picture) Docker is. I especially liked the comparison of containers to a herd of cattle, mere numbers, replaceable, whereas VMs are cats, each with their individual name, lovely petted each day, etc. ObHint: Some may have noticed I do have a Twitter account now. I do not really use it much. I got it because I wanted to rant at someone who only gave Twitter as means to contact them (a European company running a lottery for USA citizens only). But I found one nice thing: @HourlyCats (though @FacesPics and @BahnAnsagen are funny too, and the Postillon anyway). The internet is there for cat content, anyway.
Ahem. Do not contact me there, use IRC, more specifically, the Freenode network, and possibly memoserv to mirabilos instead, I can t fit things into 140 chars, that s just ridiculous. Also, don t follow me. It may contain rants, it s NSFW, and I m not censoring there. As I said: I do not use it. So should you. (But kudos for having a mostly functional fallback site (the mobile one), which even works in PocketIE (Windows Mobile) and Opera 9, though not so much lynx(1) ) odc (from #!/bin/mksh on IRC) is hacking support to use mksh instead of GNU bash for bootstrapping pkgsrc (e.g. on Solaris). Nice! Good luck! propos mksh(1), dear Debian armel and armhf buildd maintainer colleagues, pretty please with strawberries and chocolate ice on top (I just had that on waffles at my favourite ice salon, so I may be biased), do like s390x and update your chroots and wanna-build give-back mksh, as we requested, so the privacy fix makes it into jessie. Thanks in advance! Oh, and Y_Plentyn and I both have been putting more and updated packages into my APT repository. XTaran held a talk at CLT 2015 mentioning it maybe I should write up some docs about how to use it for which purposes (e.g. how to avoid systemd but not get the other packages from it, or how to use it with systemd (trivial but has to be stated, it s freedom of choice after all), etc.)? Besides decent fanfiction (the stories in the Uzumaki Naruto universe seem, on average, to be much longer than those in the Harry Potter one), the weather is becoming good, so I ve already been enjoying going out for some geocaching and will have the bike fixed at the shop RSN (it suffers a bit each winter, as it stands outside, since our basement is mouldy, which is worse than a bit of rust IMHO) to get more activity in. Also planning to head to the GPS Maze in Mainz and, besides what time FrOSCon (including preparation) allows, heading to DebConf for a while.

The organization of DebConf15 (from 15 to 22 August 2015, in Heidelberg, Germany) is going smoothly, the call for proposals is open and today we want to provide some updates about our sponsors. Twelve more companies have joined our nine first sponsors in supporting DebConf15. Thank you to all of them! Our third Gold sponsor is the Matanel Foundation, which encourages social entrepreneurship in all over the world. IBM, the technology and consulting corporation, has also joined the DebConf15 sponsorship at a Gold level. Google, the search engine and advertising company, has increased its sponsorship level from Silver to Gold. Mirantis, 1&1 (which is also one of Debian's service partners), MySQL and Hudson River Trading have committed sponsorship at Silver level. And last but not least, six more sponsors have agreed to support us at Bronze level: Godiug.net, the University of Zurich, Deduktiva, Docker, DG-i (which is also one of Debian's service partners), and PricewaterhouseCoopers (which also provides consultancy support for DebConf15). The DebConf15 team is very thankful to all the DebConf sponsors for their support. Become a sponsor too! DebConf15 is still accepting sponsors. Interested companies and organizations may contact the DebConf team through sponsors@debconf.org, and visit the DebConf15 website at http://debconf15.debconf.org.

I recently learnt that my former coworker Jonny took his efforts around his own monitoring system Bloonix and moved to self-employment. If you're considering to outsource your monitoring consider Bloonix. As a plus all the code is open under GPLv3 and available on GitHub. So if you do not like to outsource it you can still build up an instance on your own. Since this has been a one man show for a long time most of the documentation is still in german. Might be a pro for some but a minus for others, if you like Bloonix I guess documentation translations or a howto in english is welcome. Beside of that Jonny is also the upstream author of a few Perl modules like libsys-statistics-linux-perl. So another one has taken the bold step to base his living on free and open source software, something that always has my admiration. Jonny, I hope you'll succeed with this step.

I haven't blogged for a long time, but I've decided that I'm going to try to write again, at least about technical stuff. My plan was to blog about the projects I've been working on lately, the main one being the setup of the latest version of Kolab with the systems we already have at work, but I'll do that on the next days. Today I'm just going to make a list of the tools I use on a daily basis and my plans to start using additional ones in the near future. Shells, Terminals and Text Editors I do almost all my work on Z Shell sessions running inside tmux; for terminal emulation I use gnome-terminal on X, VX ConnectBot on Android systems and iTerm2 on Mac OS X. For text editing I've been using Vim for a long time (even on Mobile devices) and while I'm aware I don't know half of the things it can do, what I know is good enough for my day to day needs. In the past I also used Emacs as a programming editor and my main tool to write HTML, SGML and XML, but since I haven't really needed an IDE for a long time and I mainly use Lightweight Markup Languages I haven't used it for a long time (I briefly tried to use Org mode, but for some reason I ended up leaving it). Documentation formats and tools Since a long time ago I've been an advocate of Lightweight Markup Languages; I started to use LaTeX and Lout, then moved to SGML/XML formats (LinuxDoc and DocBook) and finally moved to plain text based formats. I started using Wiki formats (parsewiki) and soon moved to reStructuredText; I also use other markup languages like Markdown (for this blog, aka ikiwiki) and tried MultiMarkdown to replace reStructuredText for general use, but as I never liked Markdown syntax I didn't liked an extended version of it. While I've been using ReStructuredText for a long time, I recently found Asciidoctor and the Asciidoc format and I guess I'll be using it instead of rst whenever I can (I still need to try the slide backends and conversions to ODT, but if that works I guess I'll write all my new documents using Asciidoc). Programming languages I'm not a developer, but I read and patch a lot of free software code written on a lot of different programming languages (I wouldn't be able to write whole programs on most of them, but thanks to Stack Overflow I'm usually able to fix what I need). Anyway, I'm able to program in some languages; I write a lot of shell scripts and I go for Python and C when I need something more complicated. On the near future I plan to read about javascript programming and nodejs (I'll probably need it at work) and I already started looking at Haskell (I guess it was time to learn about functional programming and after reading about it, it looks like haskell is the way to go for me). Version Control For a long time I've been a Subversion user, at least for my own projects, but seems that everything has moved to git now and I finally started to use it (I even opened a github account) and plan to move all my personal subversion repositories at home and at work to git, including the move of all my debian packages from svn-buildpackage to git-buildpackage. Further Reading With the previous plans in mind, I've started reading a couple of interesting books:

• Learn You a Haskell by Miran Lipova a (http://learnyouahaskell.com/)
• Pro Git written by Scott Chacon and Ben Straub (http://git-scm.com/book/en/v2)

Now I just need to get enough time to finish reading them ... ;)

Review: Some Remarks, by Neal Stephenson

Publisher:	William Morrow
Copyright:	June 2013
ISBN:	0-06-202444-2
Format:	Trade paperback
Pages:	336

This is going to be another weird review, since I read this essay collection about three months ago, and I borrowed it from a friend. So this is both from fading memory and without a handy reference other than Internet searches. Apologies in advance for any important details that I miss. The advantage is that you'll see what parts of this collection stuck in my memory. Some Remarks is, as you might guess from the title, a rather random collection of material. There's one long essay that for me was the heart of the book (more on that in a moment), two other longer essays, two short stories, and thirteen other bits of miscellaneous writing of varying lengths. I found most of the short essays unremarkable. Stephenson uses a walking desk because sitting is bad for you that sentence contains basically all of the interesting content of one of the essays. I think it takes a large topic and some running room before Stephenson can get up to speed and produce something that's more satisfying than technological boosterism. That means the most interesting parts of this book are the three longer works. "In the Kingdom of Mao Bell" was previously published in Wired and is still available. Some Remarks contains only excerpts; Stephenson says that some of the original essay is no longer that interesting. I had mixed feelings about this one. Some of the sense of place he creates was fun to read, but Stephenson can't seem to quite believe that the Chinese don't care about "freedom" according to his definitions in the same way and therefore don't have the same political reaction to hacker culture that he does. This could have been an opportunity for him to question assumptions, but instead it's mostly an exercise in dubious, sweeping cultural evaluation, such as "the country has a long history of coming up with technologies before anyone else and then not doing a lot with them." A reminder that the detail with which Stephenson crams his writing is not always... true. Stronger is "Atoms of Cognition: Metaphysics in the Royal Society 1715 2010," which covers material familiar to readers of Stephenson's Baroque Cycle. The story of Newton, Leibniz, their rivalry, and the competing approaches to thinking about mathematics and science was my favorite part of that series, and in some ways the non-fiction treatment is better than the fictional one. If you liked the Baroque Cycle, this is worth reading. But the highlight of the book for me was "Mother Earth Mother Board." This is a long essay (50,000 words, practically a small book and the largest part of this collection) about the laying of undersea fiber-optic cables. Those who have read Cryptonomicon will recognize some of the themes here, but there's way more to this essay than there was to the bits about undersea cables in Cryptonomicon. It's mostly about technology, rather than people, which puts Stephenson on firmer ground. The bit about people reads more like a travelogue, full of Stephenson's whole-hearted admiration of people who build things and make things work. There's a bit of politics, a bit of history, a bit of tourism, and a lot of neat trivia about a part of the technological world that I'd not known much about before. I would say this is worth the price of the collection, but it too was previously published in Wired, so you can just read it online. Those reading this review on my web site will notice that I filed it in non-fiction. There are a couple of stories, but they're entirely forgettable (in fact, I had entirely forgotten them, and had to skim them again). But, for the record, here are short reviews of those: "Spew": This originally appeared in Wired and can still be read on-line. The protagonist takes a job as a sort of Internet marketing inspector who looks for deviations from expected profiles. While tracing down an anomaly, though, he finds another use of the Internet that's outside of the marketing framework he's using. It's unlikely that anyone who's been online for long will find much new in this story. Some of that is because it was originally published in 1994, but most of it is just that this isn't a very good story. Stephenson seems to have turned up his normal manic infodump to 11 to satisfy the early Wired aesthetic, and the result is a train wreck of jargon, bad slang, and superficial social observation. (3) "The Great Simoleon Caper": Originally published in TIME, this story too is still available online. It's primarily interesting because it's a story about Bitcoin (basically), written in 1995. And it's irritating for exactly the same reason that Bitcoin enthusiasm often tends to be irritating: the assumption that cryptocurrency is somehow a revolutionary attack on government-run currency systems. I'm not going to get into the ways in which this doesn't make sense given how money is used socially (David Graeber's Debt is the book to read if you want more information); just know that the story follows that path and doesn't engage with any of the social reasons why that outcome is highly unlikely. Indeed, the lengths to which the government tries to go to discredit cryptocurrency in this story are rather silly. Apart from that, this is typical early Stephenson writing. It's very in love with ideas, not as much with characterization, and consists mostly of people explaining things to each other. Sometimes this is fun, but when focused on topics about which considerably more information has become available, it doesn't age very well. (5) Overall, there was one great essay and a few interesting bits, but I wouldn't have felt I was missing much if I'd never read this collection. I borrowed Some Remarks from a friend, and I think that's about the right level of effort. If it falls into your hands, or you see it in a library, some of the essays, particularly "Mother Earth Mother Board," are worth reading, but given that the best parts are available on-line for free, I don't think it's worth a purchase. Rating: 6 out of 10

The Debian project recently welcomed the first nine sponsors for Debconf15: credativ and sipgate as Gold sponsors, Google, Farsight Security, Inc., Martin Alfke / Buero 2.0 and Ubuntu as silver sponsors, and Logilab, Netways and Hetzner as Bronze-level. But things have kept moving! The Matanel Foundation just committed to support DebConf15 as Gold-level sponsor, and Mirantis as Silver-level. So, at the time of writing this, we have 11 sponsors. We are very thankful for that! The DebConf team aims to organize the Debian Conference as a self-sustaining event, despite its size and complexity (the Final Report for DebConf14 gives a good indication). The financial contributions by individuals, companies and organizations, as well as the support by our infrastructure sponsors, media partners, and volunteers, are pivotal to our success. There are many different possibilities to support DebConf. If you know any company or organization that could be interested, don t hesitate to point them at our sponsorship brochure (also available in German) or tell us about any leads.

During 2 years, my packaging efforts were sponsored by eNovance. It has been great to work with them, and I would like to thank them for what they did. However (for a number of reasons which I don t really think is appropriate to write in this blog), I decided to join Mirantis. This is a formal public announce of it: I will be working from Mirantis office in Grenoble just right after the Paris OpenStack summit of this first week of November.

A little more than 2 years ago, the Ceilometer project was launched inside the OpenStack ecosystem. Its main objective was to measure OpenStack cloud platforms in order to provide data and mechanisms for functionalities such as billing, alarming or capacity planning. In this article, I would like to relate what I've been doing with other Ceilometer developers in the last 5 months. I've lowered my involvement in Ceilometer itself directly to concentrate on solving one of its biggest issue at the source, and I think it's largely time to take a break and talk about it. Ceilometer early design For the last years, Ceilometer didn't change in its core architecture. Without diving too much in all its parts, one of the early design decision was to build the metering around a data structure we called samples. A sample is generated each time Ceilometer measures something. It is composed of a few fields, such as the the resource id that is metered, the user and project id owning that resources, the meter name, the measured value, a timestamp and a few free-form metadata. Each time Ceilometer measures something, one of its components (an agent, a pollster ) constructs and emits a sample headed for the storage component that we call the collector. This collector is responsible for storing the samples into a database. The Ceilometer collector uses a pluggable storage system, meaning that you can pick any database system you prefer. Our original implementation has been based on MongoDB from the beginning, but we then added a SQL driver, and people contributed things such as HBase or DB2 support. The REST API exposed by Ceilometer allows to execute various reading requests on this data store. It can returns you the list of resources that have been measured for a particular project, or compute some statistics on metrics. Allowing such a large panel of possibilities and having such a flexible data structure allows to do a lot of different things with Ceilometer, as you can almost query the data in any mean you want. The scalability issue We soon started to encounter scalability issues in many of the read requests made via the REST API. A lot of the requests requires the data storage to do full scans of all the stored samples. Indeed, the fact that the API allows you to filter on any fields and also on the free-form metadata (meaning non indexed key/values tuples) has a terrible cost in terms of performance (as pointed before, the metadata are attached to each sample generated by Ceilometer and is stored as is). That basically means that the sample data structure is stored in most drivers in just one table or collection, in order to be able to scan them at once, and there's no good "perfect" sharding solution, making data storage scalability painful. It turns out that the Ceilometer REST API is unable to handle most of the requests in a timely manner as most operations are O(n) where n is the number of samples recorded (see big O notation if you're unfamiliar with it). That number of samples can grow very rapidly in an environment of thousands of metered nodes and with a data retention of several weeks. There is a few optimizations to make things smoother in general cases fortunately, but as soon as you run specific queries, the API gets barely usable. During this last year, as the Ceilometer PTL, I discovered these issues first hand since a lot of people were feeding me back with this kind of testimony. We engaged several blueprints to improve the situation, but it was soon clear to me that this was not going to be enough anyway.

Thinking outside the box Unfortunately, the PTL job doesn't leave him enough time to work on the actual code nor to play with anything new. I was coping with most of the project bureaucracy and I wasn't able to work on any good solution to tackle the issue at its root. Still, I had a few ideas that I wanted to try and as soon as I stepped down from the PTL role, I stopped working on Ceilometer itself to try something new and to think a bit outside the box. When one takes a look at what have been brought recently in Ceilometer, they can see the idea that Ceilometer actually needs to handle 2 types of data: events and metrics. Events are data generated when something happens: an instance start, a volume is attached, or an HTTP request is sent to an REST API server. These are events that Ceilometer needs to collect and store. Most OpenStack components are able to send such events using the notification system built into oslo.messaging. Metrics is what Ceilometer needs to store but that is not necessarily tied to an event. Think about an instance CPU usage, a router network bandwidth usage, the number of images that Glance is storing for you, etc These are not events, since nothing is happening. These are facts, states we need to meter. Computing statistics for billing or capacity planning requires both of these data sources, but they should be distinct. Based on that assumption, and the fact that Ceilometer was getting support for storing events, I started to focus on getting the metric part right. I had been a system administrator for a decade before jumping into OpenStack development, so I know a thing or two on how monitoring is done in this area, and what kind of technology operators rely on. I also know that there's still no silver bullet this made it a good challenge. The first thing that came to my mind was to use some kind of time-series database, and export its access via a REST API as we do in all OpenStack services. This should cover the metric storage pretty well. Cooking Gnocchi

A cloud of gnocchis!

At the end of April 2014, this led met to start a new project code-named Gnocchi. For the record, the name was picked after confusing so many times the OpenStack Marconi project, reading OpenStack Macaroni instead. At least one OpenStack project should have a "pasta" name, right? The point of having a new project and not send patches on Ceilometer, was that first I had no clue if it was going to make something that would be any better, and second, being able to iterate more rapidly without being strongly coupled with the release process. The first prototype started around the following idea: what you want is to meter things. That means storing a list of tuples of (timestamp, value) for it. I've named these things "entities", as no assumption are made on what they are. An entity can represent the temperature in a room or the CPU usage of an instance. The service shouldn't care and should be agnostic in this regard. One feature that we discussed for several OpenStack summits in the Ceilometer sessions, was the idea of doing aggregation. Meaning, aggregating samples over a period of time to only store a smaller amount of them. These are things that time-series format such as the RRDtool have been doing for a long time on the fly, and I decided it was a good trail to follow. I assumed that this was going to be a requirement when storing metrics into Gnocchi. The user would need to provide what kind of archiving it would need: 1 second precision over a day, 1 hour precision over a year, or even both. The first driver written to achieve that and store those metrics inside Gnocchi was based on whisper. Whisper is the file format used to store metrics for the Graphite project. For the actual storage, the driver uses Swift, which has the advantages to be part of OpenStack and scalable. Storing metrics for each entities in a different whisper file and putting them in Swift turned out to have a fantastic algorithm complexity: it was O(1). Indeed, the complexity needed to store and retrieve metrics doesn't depends on the number of metrics you have nor on the number of things you are metering. Which is already a huge win compared to the current Ceilometer collector design. However, it turned out that whisper has a few limitations that I was unable to circumvent in any manner. I needed to patch it to remove a lot of its assumption about manipulating file, or that everything is relative to now (time.time()). I've started to hack on that in my own fork, but then everything broke. The whisper project code base is, well, not the state of the art, and have 0 unit test. I was starring at a huge effort to transform whisper into the time-series format I wanted, without being sure I wasn't going to break everything (remember, no test coverage). I decided to take a break and look into alternatives, and stumbled upon Pandas, a data manipulation and statistics library for Python. Turns out that Pandas support time-series natively, and that it could do a lot of the smart computation needed in Gnocchi. I built a new file format leveraging Pandas for computing the time-series and named it carbonara (a wink to both the Carbon project and pasta, how clever!). The code is quite small (a third of whisper's, 200 SLOC vs 600 SLOC), does not have many of the whisper limitations and it has test coverage. These Carbonara files are then, in the same fashion, stored into Swift containers. Anyway, Gnocchi storage driver system is designed in the same spirit that the rest of OpenStack and Ceilometer storage driver system. It's a plug-in system with an API, so anyone can write their own driver. Eoghan Glynn has already started to write a InfluxDB driver, working closely with the upstream developer of that database. Dina Belova started to write an OpenTSDB driver. This helps to make sure the API is designed directly in the right way. Handling resources Measuring individual entities is great and needed, but you also need to link them with resources. When measuring the temperature and the number of a people in a room, it is useful to link these 2 separate entities to a resource, in that case the room, and give a name to these relations, so one is able to identify what attribute of the resource is actually measured. It is also important to provide the possibility to store attributes on these resources, such as their owners, the time they started and ended their existence, etc.

Relationship of entities and resources

Once this list of resource is collected, the next step is to list and filter them, based on any criteria. One might want to retrieve the list of resources created last week or the list of instances hosted on a particular node right now. Resources also need to be specialized. Some resources have attributes that must be stored in order for filtering to be useful. Think about an instance name or a router network. All of these requirements led to to the design of what's called the indexer. The indexer is responsible for indexing entities, resources, and link them together. The initial implementation is based on SQLAlchemy and should be pretty efficient. It's easy enough to index the most requested attributes (columns), and they are also correctly typed. We plan to establish a model for all known OpenStack resources (instances, volumes, networks, ) to store and index them into the Gnocchi indexer in order to request them in an efficient way from one place. The generic resource class can be used to handle generic resources that are not tied to OpenStack. It'd be up to the users to store extra attributes. Dropping the free form metadata we used to have in Ceilometer makes sure that querying the indexer is going to be efficient and scalable.

The indexer classes and their relations

REST API All of this is exported via a REST API that was partially designed and documented in the Gnocchi specification in the Ceilometer repository; though the spec is not up-to-date yet. We plan to auto-generate the documentation from the code as we are currently doing in Ceilometer. The REST API is pretty easy to use, and you can use it to manipulate entities and resources, and request the information back.

Macroscopic view of the Gnocchi architecture

Roadmap & Ceilometer integration All of this plan has been exposed and discussed with the Ceilometer team during the last OpenStack summit in Atlanta in May 2014, for the Juno release. I led a session about this entire concept, and convinced the team that using Gnocchi for our metric storage would be a good approach to solve the Ceilometer collector scalability issue. It was decided to conduct this project experiment in parallel of the current Ceilometer collector for the time being, and see where that would lead the project to. Early benchmarks Some engineers from Mirantis did a few benchmarks around Ceilometer and also against an early version of Gnocchi, and Dina Belova presented them to us during the mid-cycle sprint we organized in Paris in early July. The following graph sums up pretty well the current Ceilometer performance issue. The more you feed it with metrics, the more slow it becomes.

For Gnocchi, while the numbers themselves are not fantastic, what is interesting is that all the graphs below show that the performances are stable without correlation with the number of resources, entities or measures. This proves that, indeed, most of the code is built around a complexity of O(1), and not O(n) anymore. Next steps

Cl ment drawing the logo

While the Juno cycle is being wrapped-up for most projects, including Ceilometer, Gnocchi development is still ongoing. Fortunately, the composite architecture of Ceilometer allows a lot of its features to be replaced by some other code dynamically. That, for example, enables Gnocchi to provides a Ceilometer dispatcher plugin for its collector, without having to ship the actual code in Ceilometer itself. That should help the development of Gnocchi to not be slowed down by the release process for now. The Ceilometer team aims to provide Gnocchi as a sort of technology preview with the Juno release, allowing it to be deployed along and plugged with Ceilometer. We'll discuss how to integrate it in the project in a more permanent and strong manner probably during the OpenStack Summit for Kilo that will take place next November in Paris.

Review: Parasite, by Mira Grant

Series:	Parasitology #1
Publisher:	Orbit
Copyright:	October 2013
ISBN:	0-316-21893-6
Format:	Kindle
Pages:	504

It's 2027, and a company named Symbogen has revolutionized medicine and health. They manufacture a genetically-engineered parasite based on a tapeworm that can stabilize and protect the health of just about anyone. It can synthesize medication, fix chronic medical problems, and be adapted to different conditions. (Yes, I know biological systems don't work this way. That's not going to be the only suspension of disbelief problem.) This has made Symbogen one of the most powerful corporations in the country, aided by the skill at marketing and self-promotion shown by one of the founders. Sal, the protagonist of the novel, is one of Symbogen's most famous success stories. Sally was the victim of a horrible car crash that put her into an apparently irreversible coma. But as her family was debating whether to turn off life support, she woke up. She had no memory of her previous life at all, and had to relearn fine motor control, reading, and many other skills. She was essentially a new person. But she was alive; her symbiont had saved her. When the story proper starts, Sal is still a ward of her parents. She has generally adult skills despite still struggling with reading, but she still has occasional attacks and is under intensive monitoring by Symbogen. That means periodic mandatory appointments with Symbogen, which she hates, but she's otherwise started building a life for herself: a job in an animal shelter, an interest in exotic predatory plants, and, most notably, a boyfriend. There are things about her life she doesn't like, and she wants to be free of Symbogen, but she doesn't have a bad life. But then a mysterious illness begins sweeping through the population, causing people to go blank, apparently lose their minds, and then start attacking those near them. Some of you have doubtless already figured out the key plot revelation. It's not hard; even if you didn't from the summary, you will probably figure it out shortly into the book. And therein lies a large problem with this novel: it's hopelessly predictable. Creepy evil corporation that supposedly has your best interests at heart, check. Plucky mad scientist opposition who understands exactly what's going on, check. Well-meaning but heavy-handed government agents who try to get involved but mostly make everything worse, check. (Although it's unusual to have those agents as part of the protagonist's family, and I thought that added some additional depth.) Mostly clueless protagonist sucked into the plot and becoming critical to its resolution, check. Very few readers are going to be surprised by this story. This is not, by itself, a fatal flaw. Predictable story structures can carry satisfying variations, or introduce the reader to enjoyable characters. And I think Grant manages both here. Seanan McGuire, both as herself and under her Mira Grant pseudonym, tends to write damaged and struggling characters. Both her Newsflesh and October Daye series feature protagonists that have been hurt badly, but are coping and muddling through in their own ways. In Parasite, I think she takes a more daring and intriguing approach: a protagonist that other people in the story perceive as damaged and struggling, but who actually isn't. Sal is not a badly injured Sally, and she's quite a bit healthier than those around her think she is. Her thought processes don't work quite the same as those around her, but that's not because she's hurt. That's because she's a different person. This makes Parasite partly a novel about identity, about Sal claiming ownership of her own life. Grant drags this out longer than I wish she had, but I liked the idea. In Sal, she strikes a good balance between gratitude and genuine affection for her family and the need to become her own person unconstrained by other people's expectations. As with the Newsflesh series, Grant uses quotes and excerpts from interviews to fill in the world background: a few at the start of each chapter, and more around each part boundary. I like this technique, and Grant uses it well. By the end of the book, the Rolling Stone interview with the head of Symbogen has added a lot of insight into how Symbogen manages its public relations. Grant also throws in a few of her trademark dangerously off-beat characters: hyper-competent, wise-cracking, but eerily skewed. I loved those in Blackout and I loved Tansy and Dr. Cale here. (Adam was much less successful.) A whole book from Tansy's perspective wouldn't work, since she needs Sal as a straight woman, but I thought she stole every scene she was in. However, I agree wholeheartedly with Tansy on another point: Sal is remarkably, irritatingly dim about what is apparently intended to be the critical revelation of the book. I won't state it outright; given its significant presence in the final scene, apparently it is intended to be a spoiler. But I figured it out about 50 pages into the book. Grant telegraphs this revelation heavily, and Tansy considers it painfully obvious (with quite a bit of justification). But Sal doesn't figure it out for the entire book, ignores all the signs, and is apparently willfully blind. In a book written from the first-person perspective by an otherwise-reliable narrator, this is highly annoying. It significantly undermined my enjoyment of the book. I spent much of the novel ahead of the narrator in my understanding of the plot and waiting, in vain, for her to get on with it already. That unfortunately makes Parasite a mixed bag. I really liked many of the characters, and I think Grant did some interesting things with family dynamics and with claiming one's own identity. But this is undermined by a very predictable plot, the protagonist deciding to be dumber than a sack of hammers about a critical plot point, and some rather dubious world logic. (For example, why is Sal terrified of bad driving? It makes sense as a post-traumatic stress reaction... except it's a critical point to her characterization that she never went through that stress.) Sometimes I wanted to like this book and sometimes I wanted to shake it, and sometimes I felt both reactions at the same time. I like Grant's writing and characterization well enough that I will probably read the sequel, but this is more like the later books in the Newsflesh series than it is like the spectacular Feed. Worth reading, at least for me, but it could have been better. Rating: 7 out of 10

Time for an update from my internship at Mozilla, as part of the OPW. The last weeks have been a bit rough: I have my usual migraines to thank for that. It's not easy to work with them: you are either stoned by the meds, or cannot look at a monitor. And while you're trying to sleep your headaches away, the world keeps rolling. Silly world.
As Liz, my mentor, suggested I tried to stick with the little things and to do a bit of something everyday.
"Waiting for the miracle", you know.
So, here's what I've been up to: Triaging I probably failed my personal 5-bugs-a-day policy, in the last two weeks, but beside that I'm pretty satisfied of my progress:

• I learnt how to find regression windows
• I verified some more bugs (mostly Developer Tools or Theme related) on both Linux and Windows (yeah. Don't.Ask.)
• I triaged a lot of them. Also botched a couple, and felt an idiot for that.

All in all, I realized that I really love triaging/verifying bugs: being not a developer nor a simple user, but a bit of both, gives me the right mindset - I think - to mediate between these two worlds. Community On the community front, I finally managed to meet - virtually - the Mozilla Italian community. The guys are great and beside running the forum to give user support, they do a whole lot of activities related to localization. They are also trying to encourage participation of Italian users and enthusiasts to Mozilla events: don't miss, for instance, the upcoming Marketplace Day when a couple of us will be available to help other Italian users with the day's activities. Read Daniele's post on the forum for more information in Italian. Documentation On the documentation front, I finally managed to get out the Bugdays FAQ, draft a guide on how to run different versions of Firefox and multiple profiles for triaging purposes on Linux and Windows - still have to finish this one, though -, and participate to a very interesting discussion on the current state of QMO - the entry point for QA contributors in Mozilla.
The site, in my opinion, needs some love and I'd very much like to help in that sense.
Check out the discussion, and give us some feedback about the website on the dev-quality mailing list! Lessons learned

• when you're not feeling well, stick with the little things and don't feel guilty for that
• don't try to reproduce a bug when you're tired, you'll end up Doing It Wrong

Sorry about the lack of posting recently. Work has been rather problematic, and also very distracting, and on my time away from work I've been relaxing rather than writing. Didn't even get reviews written while on vacation. I am still hoping to catch up on reviews, however. In the meantime, I have been reading some, and buying more books. Here's a new haul list. Elizabeth Bear Steles of the Sky (sff)
Katherine Boo Behind the Beautiful Forevers (non-fiction)
John Chu The Water That Falls on You from Nowhere (sff)
Lewis Dartnell The Knowledge (non-fiction)
David Lochbaum, et al. Fukushima (non-fiction)
Ben Goldacre Bad Pharma (non-fiction)
Mira Grant Parasite (sff)
Thomas Olde Heuvelt The Ink Readers of Doi Saket (sff)
Mary Robinette Kowal The Lady Astronaut of Mars (sff)
Madeline Miller The Song of Achilles (historical)
Edmund S. Morgan American Slavery, American Freedom (non-fiction)
Richard Rhodes The Making of the Atomic Bomb (non-fiction)
Lee Smolin The Trouble with Physics (non-fiction)
Charles Stross Equoid (sff)
Charles Stross Neptune's Brood (sff) This is a bit of a grab-bag, including a variety of non-fiction that I had recommended to me by various people. I also picked up the remaining Hugo nominees for best novel that won't be in the voter packet, and the short fiction from Tor.com that was nominated and was available for free from Amazon for the Kindle. I read The Knowledge while I was on vacation, and it's in my large backlog of pending reviews.

I spent the bank holiday weekend mostly in Manchester with my brother and a couple of friends, mostly to see Nine Inch Nails perform, but also to enjoy the pleasures of the city. We arrived on the Sunday and after checking in headed out to get some food. I'd booked us a table at the historic Marble Arch - the pub which gives its name to the parent company Marble Beers - and produce my most favourite ales. Whenever a Marble beer ends up as a guest at one of the Newcastle real ale pubs a friend of mine (who is much more on top of this stuff than I am) lets me know and we stop off for a few. Invariably there's a crowd of a dozen or so Manchester expats in bar when we do. I reserved our table over twitter, which is a bit of a novelty for me. My two friends are ale skeptics but - due to lack of choice - we all ended up sampling the Chocolate Marble and the Ginger 5.1, which went down a storm. They are possibly converts now. There was an Earl Grey IPA too, which was nice but a bit on the strong side for sessioning. The gig was great - I prefer club gigs to arena gigs but the sound techs for NIN know what they are doing and the mix was great. The visuals were stunning too. Highlights for me were "The Great Destroyer" - in particular the extended, improvised 5 minute glitch-meltdown coda; the slow build of "Eraser" and "The Day The World Went Away" - played faithfully to the CD mix rather than the traditional extended live arrangement. I miss the former live arrangement, which includes a drawn out drum-backed finish, but this arrangement had a lot of force, with all four of the band bashing guitars into a pummelling wall of sound. I've heard that at least one person has taped the show and it turns out recordings have just recently surfaced for the two club gigs my brother and I attended back in 2005 and 2007 - meaning there are now widely available, high quality ROIO copies for every NIN gig I've ever been to. Afterwards we tried to find a decent club. Manchester is a lot larger than my native city and there's plenty of places to go, if you know where they are. We had originally planned to visit The Factory on Charles Street, but we didn't believe it was open on the Sunday. The Factory is Peter Hook's (formerly of Joy Division/New Order) club - occupying the former office spaces of Factory records. I've chanced in there once before as it's right across the road from the Lass O' Gowrie pub, which is the haunt of choice for HE/tech people whenever we're in Manchester for conferences. Instead we gravitated towards Dry Bar on Oldham street. By coincidence this place also has historic ties to Factory Records. However the doormen wouldn't let us in! Finally we landed at a place which had one name on the door and a different name on the inside (Jack's). Like the aformentioned Lass O' Gowrie and perhaps half of all pubs and clubs in Manchester, the place is decked out as a shrine to the former musical giants of the City, with framed pictures of Mark E Smith, the Ha ienda again, the Stone Roses in their boy-band-looks hay day, John Peel (champion of many of them) and of course Tony Wilson. I can't help but wonder whether people who live here get royally sick of that. This place served some delicious albeit clich -titled Cocktails and played a pretty good set - the obligatory Madchester throwback interlude was followed by a chunk of Northern Soul and a couple of early Rap classics. Setlist wise it was pretty much identical to that of Foundation in Newcastle, 12 years ago, no doubt because Foundation was cribbing heavily from the Ha ienda in the first place. Monday was dedicated to exploring and shopping. Top of my list of places to go was my pilgrimage venue Vinyl Exchange. Whilst waiting for it to open we rolled around in Affleck's Palace, which turned out to have a small record stall within. After Vinyl Exchange we chanced across another record store right across the road - Picadilly Records - which happens to be larger and focuses more on new releases. It didn't take long before we found another small, DIY record shop, then another. We tried out the Fopp branch here - more Vinyl; then Urban Outfitters - more; then an Oxfam branch - even more. I actually got Vinyl snow blind at this point. I've been controlling myself admirably and only picked up a couple of bits and pieces. My best find was Fad Gadget's sophmore album "Incontinent".

Today was a really good day, right up until the end, when it wasn't so good, but could have been a whole lot worse, so I'm grateful for that. I've been wanting to walk out to King Island at low tide with Zoe for a while, but it's taken about a month to get the right combination of availability, weather and low tide timing to make it possible. Today, there was a low tide at about 10:27am, which I thought would work out pretty well. I wasn't sure if the tide needed to be dead low to get to King Island, so I thought we could get there a bit early and possibly follow the tide out. I invited Megan and Jason to join us for the day and make a picnic of it. It turned out that we didn't need a really low tide, the sand bar connecting King Island to Wellington Point was well and truly accessible well before low tide was reached, so we headed out as soon as we arrived. I'd brought Zoe's water shoes, but from looking at it, thought it would be walkable in bare feet. We got about 10 metres out on the sand and Zoe started freaking out about crabs. I think that incident with the mud crab on Coochiemudlo Island has left her slightly phobic of crabs. So I went back to Jason's car and got her water shoes. I tried to allay her fears a bit by sticking my finger in some of the small holes in the sand, and even got her to do it too. I'm actually glad that I did get her water shoes, because the shell grit got a bit sharp and spiky towards King Island, so I probably would have needed to carry her more than I did otherwise. Along the way to the island we spotted a tiny baby mud crab, and Zoe was brave enough to hold it briefly, so that was good. We walked all the way out and partially around the island and then across it before heading back. The walk back was much slower because where was a massive headwind. Zoe ran out of steam about half way back. She didn't like the sand getting whipped up and stinging her legs, and the wind was forcing the brim of her hat down, so I gave her a ride on my shoulders for the rest of the way back. We had some lunch after we got back to Wellington Point, and Zoe found her second wind chasing seagulls around the picnic area. After an ice cream, we went over to the playground and the girls had a great time playing. It was a pretty good park. There was this huge tree with a really big, thick, horizontal branch only about a metre or two off the ground. All the kids were climbing on it and then shimmying along the branch to the trunk. Zoe's had a few climbs in trees and seems not afraid of it, so she got up and had a go. She did really well and did a combination of scooting along, straddling the branch and doing a Brazilian Jiu-Jitsu-style "bear crawl" along the branch. It was funny seeing different kids' limits. Zoe was totally unfazed by climbing the tree. Megan was totally freaking out. But when it came to walking in bare feet in an inch of sea water, Zoe wanted to climb up my leg like a rat up a rope, in case there were crabs. Each to their own. Zoe wanted to have a swim in the ocean, so I put her into her swimsuit, but had left the water shoes back in the car. Once again, she freaked out about crabs as soon as we got ankle deep in the water, and was freaking out Megan as well, so the girls elected to go back to playing in the park. After a good play in the park, we headed back home. We'd carpooled in Jason's truck, with both girls in the back. I'd half expected Zoe to fall asleep on the way back, but the girls were very hyped up and had a great time playing games and generally being silly in the back. When we got back to our place, Jason was in need of a coffee, so we walked to the Hawthorne Garage and had coffee and babyccinos, before Megan and Jason went home. It was about 3:30pm at this point, and I wanted to make a start on dinner. I was making a wholemeal pumpkin quiche, which I've made a few times before, and I discovered we were low on linseed. I thought I'd push things and see if Zoe was up for a scooter ride to the health food shop to get some more and kill some time. She was up for it, but ran out of steam part way across Hawthorne Park. Fortunately she was okay with walking and didn't want me to carry her and the scooter. It took us about an hour to get to the health food shop. Zoe immediately remembered the place from the previous week where we'd had to stop for a post-meltdown pit stop and declared she needed to go to the toilet again. We finally made it out of the shop. I wasn't looking forward to the long walk back home, but there were a few people waiting for a bus at the bus stop near the health food shop, and on checking the timetable, the bus was due in a couple of minutes, so we just waited for the bus. That drastically shortened the trip back. Zoe managed to drop the container of linseed on the way home from the bus stop, but miraculously the way it landed didn't result in the loss of too much of the contents, it just split the container. So I carefully carried the container home the rest of the way. By this stage it was quite a bit later than I had really wanted to be starting dinner, but we got it made, and Zoe really liked the pumpkin quiche, and ate a pretty good dinner. It was after dinner when things took a turn for the worse. Zoe was eating an ice block for dessert, and for whatever reason, she'd decided to sit in the corner of the kitchen next to the dishwasher, while I was loading it. I was carrying over one of the plates, and the knife managed to fall off the plate, bounce off the open dishwasher door and hit her in the mouth, splitting her lip. Zoe was understandably upset, and I was appalled that the whole thing had happened. She never sits on the kitchen floor, let alone in the corner where the dishwasher is. And this knife came so close to her eye. Fortunately the lip didn't look too bad. It stopped bleeding quickly, and we kept some ice on it and the swelling went down. I hate it when accidents happen on my watch. I feel like I'm fighting the stigma of the incompetent single Dad, or the abusive single Dad, so when Zoe sustains an injury to the face like a fat lip, which could be misinterpreted, I, well, really hate it. This was such a freak accident, and it could have gone so much worse. I'm just so glad she's okay. Zoe recovered pretty well from it, and I was able to brush her teeth without aggravating her lip. She went to bed well, and I suspect she's going to sleep really well. It's a bit cooler tonight, so I'm half-expecting a sleep in in the morning with any luck.

Q: The title for a governor in ancient Persia? A: It s satrap!

Shanley wrote an insightful article about microagressions and management [1]. It s interesting to read that and think of past work experiences, even the best managers do it. Bill Stone gave an inspiring TED talk about exploring huge caves, autonamous probes to explore underground lakes (which can be used on Europa) and building a refuelling station on the Moon [2]. Simon Lewis gave an interesting TED talk about consciousness and the technology needed to help him recover from injuries sustained in a serious car crash [3]. Paul Wayper wrote an interesting article about reforming the patent system [4]. He also notes that the patent system is claimed to be protecting the mythical home inventor when it s really about patent trolls (and ex-inventors who work for them). This is similar to the way that ex-musicians work for organisations that promote extreme copyright legislation. Amanda Palmer gave an interesting TED talk about asking for donations/assistance, and the interactions between musicians and the audience [5]. Some part of this are NSFW. Hans Rakers wrote a useful post about how to solve a Dovecot problem with too many files open [6]. His solution was for a Red Hat based system, for Debian you can do the same but by editing /etc/init.d/dovecot. The use of the /proc/N/limits file was interesting, I ve never had a cause to deliberately use that file before. Krebs on Security has an interesting article about Android malware being used to defeat SMS systems to prevent bank fraud [7]. Apparently an infected PC will instruct the user to install an Android app to complete the process. Rick Falkvinge wrote an interesting article about how to apply basic economics terminology to so-called Intellectual Property [8]. Matthew Garrett wrote an interesting post about the way that Ubuntu gets a better result than Debian and Fedora because it has clear fixed goals [9]. He states that many people regard Fedora as a playground to produce a range of niche derivatives , probably a large portion of the Fedora and Debian developers consider this a feature not a bug. Ming Thein wrote an interesting article about the demise of the DSLR [10]. Bruce Schneier wrote an interesting post on the detention of David Miranda by the British authorities [11]. It s mostly speculation as to why they would do such a thing (which seems to go against their own best interests) and whether the NSA even knows which documents Edward Snowden copied. Jaclyn Friedman wrote an interesting article on Mens Rights Movements (MRAs) and how they are bad for MEN as well as for women [12]. Rodney S. Tucker wrote an insightful article for the IEEE about the NBN [13]. Basically the Liberal party are going to spend most of the tax money needed for a full NBN but get a significantly less than the full benefit. Lauren Drell wrote an interesting article for Mashable about TellSpec, a portable spectrometer that communicates with an Android phone to analyse food for allergens [14]. I guess this will stop schools from banning phones. Katie McDonough wrote an interesting article for Salon about the Pope s statements about the problems with unchecked capitalism [15]. His ideas are really nothing new to anyone who has read the Bible and read the news. It seems to me that the most newsworthy part of this is that most Christian leaders don t make similar statements. Daniel Leidert wrote an interesting post about power saving when running Debian on a HP Microserver [16]. Most of it is relevant to other AMD64 hardware too, I ll have to investigate the PCIE ASPM and spin down options on some of my systems that are mostly idle.

• [1] https://medium.com/about-work/65d4740f7a2f
• [2] http://www.ted.com/talks/bill_stone_explores_the_earth_and_space.html
• [3] http://tinyurl.com/6zgcb3f
• [4] http://mabula.net/tbfw/2013/08/01
• [5] http://www.ted.com/talks/amanda_palmer_the_art_of_asking.html
• [6] http://tinyurl.com/k3xz9a8
• [7] http://krebsonsecurity.com/2013/08/a-closer-look-perkele-android-malware-kit/
• [8] http://tinyurl.com/orf9gds
• [9] http://mjg59.dreamwidth.org/27517.html
• [10] http://blog.mingthein.com/2013/08/24/the-demise-of-the-dslr/
• [11] https://www.schneier.com/blog/archives/2013/08/detaining_david.html
• [12] http://prospect.org/article/good-mens-rights-movement-hard-find
• [13] http://tinyurl.com/q49b9fa
• [14] http://mashable.com/2013/11/26/tellspec/
• [15] http://tinyurl.com/nosxkj2
• [16] http://www.wgdd.de/2013/08/hp-n54l-microserver-energy-efficiency.html

Review: Captain Vorpatril's Alliance, by Lois McMaster Bujold

Series:	Vorkosigan #14
Publisher:	Baen
Copyright:	November 2012
ISBN:	1-4516-3845-0
Format:	Kindle
Pages:	432

This is the fourteenth book in the long-running Vorkosigan series (not counting a few side works). It shifts viewpoint characters, following Ivan Vorpatril instead of either Miles or Cordelia, and could be read on its own since the necessary background is at least briefly explained. But it's probably best read in its proper context in the larger series, since otherwise many of the prior events mentioned here won't have much resonance. Ivan Vorpatril, Miles's cousin, has appeared in multiple previous books along with the rest of Miles's extended family, but he's stayed out of the center of the plot. And he clearly likes it that way. Ivan is not at all ambitious, tries to avoid politics, and just wants to live a quiet life (insofar as that's possible in the Barrayan military), sleep with a few women, and stay out of trouble. But given his relations and his job as aide-de-camp to an admiral this doesn't always work. In this book, the not working comes in the form of Byerly, ImpSec (Imperial Security, the Barrayan equivalent of the CIA), and a request to find out more about a woman who seems to be the target of a bounty. Fairly quickly, Ivan finds himself hopelessly entangled in both politics and in someone else's complex life, and is not entirely sure what to do about either. It's been months since I read this book and I'm only now writing a review, in part because I find it hard to know what to say about it. While Ivan doesn't have Miles's manic energy, the tone of this book is very similar to the rest of the Vorkosigan series, as is the plot and most of the characters. Ivan tries a more laid-back approach and doesn't actively seek danger the way that Miles does, but his persistent efforts to do the right thing in the face of unexpected events lead mostly to the same places. There's a bit of humor, a bit of danger, some galactic politics, some scheming, and a slow process of understanding other people better in short, Captain Vorpatril's Alliance is very similar to the thirteen books that proceeded it. This is obviously not a bad thing. If you've read this far in the series, more of the same is probably just fine. I enjoyed the book. Bujold is great at telling stories, the plot mostly moved right along, and I quite liked the two women Ivan meets over the course of the story. But there wasn't much about the story that grabbed me or, I suspect, that I will find particularly memorable. One reason for my somewhat "meh" reaction is that the core of this story is a romance, and while much of that romance is well-done, there is a large segment in the middle of the book where the suspense of the plot derives mostly from one of the two characters refusing to confide in the other. This is Bujold, so this isn't as much of a train wreck as it might be in the hands of another author, and it is for valid plot reasons. But even with those justifications, I never like that plot element. There were about a hundred pages where I wanted to grab Tej and shake some sense into her, which doesn't endear a character to me. And the leads in a romance, at least this sort of romance, should be endearing. I think one reason why Bujold went for that approach to building tension is that there weren't a lot of options available. The basic outlines of what's going to happen are obvious from early in the book and essentially forced by the structure of the series. We know from past books that Ivan is both trustworthy and related to a staggering variety of powerful people, almost all of whom are highly competent and honorable. It's fairly obvious that, as soon as the necessary people trust Ivan and let him and his family solve their problems, all the problems will be solved. It's also fairly obvious how the romances will play out, and that all the new characters will end up a little in awe of how competent and trustworthy all the Barrayans are (a few misdirections aside). Therefore, much of the book, for a long-time reader of the series, involves waiting until those things happen, and meanwhile getting increasingly annoyed at characters who refuse to trust obviously trustworthy people. All that said, I still quite liked the beginning of the book, because Tej and Rish are a wonderful pair and have a great interpersonal dynamic, and the very end of the book once everyone gets past the communication problems and the plot can deliver on its promises. Both together make up for some noticeable sagging in the middle section of the book. Captain Vorpatril's Alliance is not up to the standards of the most memorable books of the series, but it's a solid dose of "more of the same" and provides its money's worth of entertainment. I'm still hoping for more Ekaterin and more fireworks in the next book, though. Rating: 7 out of 10

Despite the fact that I've had very little time to either read or write reviews, I haven't stopped buying a few books here and there. And, of course, Powell's Indiespensable keeps coming. Matt Bell In the House Upon the Dirt Between the Lake and the Woods (mainstream)
Steven Brust Orca (sff)
Steven Brust Dragon (sff)
John W. Campbell Collected Editorials from Analog (non-fiction)
Jane Fletcher The Walls of Westernfort (sff)
Mira Grant How Green This Land, How Blu This Sea (sff)
Tate Hallaway Tall, Dark, & Dead (sff)
Diana Wynne Jones Howl's Moving Castle (sff)
Rebecca Lee Bobcat and Other Stories (mainstream)
Victor Lombardi Why We Fail (non-fiction)
George R.R. Martin & Gardner Dozois (ed.) Songs of Love and Death (sff anthology)
Seanan McGuire In Sea-Salt Tears (sff)
Seanan McGuire Late Eclipses (sff)
Justina Robson Selling Out (sff)
John Scalzi Muse of Fire (sff)
Mark Slouka Brewster (mainstream)
Tor.com (ed.) The Stories (sff anthology)
Carrie Vaughn Kitty and the Midnight Hour (sff) This is a wide variety of random stuff, including some stuff that was free (the Tor.com anthology, which is every piece of short fiction they've published and is about 4000 pages, the Campbell editorials from the Internet Archive) and a lot of stuff that was on sale. As well as another two shipments of Indiespensible. The Brust books I've already read and are already in the family, but I hooked a friend of mine on the Vlad Taltos series, and those were the only two that I both didn't have and that weren't available on Kindle. So I picked them up while he was visiting so that he could read the whole series.

XMir's been delayed from Ubuntu 13.10. The stated reason is that multi-monitor support isn't sufficiently reliable. That's true, but it's far from the only problem that XMir still has:

• It's still broken on some single-monitor systems

Some machines have display corruption. There are writes to freed memory. To be fair, some of the behaviour that's been seen has been down to underlying bugs in the Xorg drivers that were never triggered under normal use but are hit by XMir. Others are down to implicit assumptions made in the drivers that XMir happens to violate. The problem is that there doesn't appear to have been enough room in the schedule to deal with these interactions, presumably because nobody accounted for the inevitable "This thing we thought would be easy turns out to be difficult" part of the project.


• The input driver bug still isn't really fixed

I've mentioned this bug before. It's now marked "Fix released" which is kind of true but not really. Mir now tells XMir that the VT is changing before the VT is changed, but it doesn't wait for that to complete before switching the VTs. Until XMir is scheduled and runs, it's still receiving input events. In most circumstances that window is small, so there's no real risk of triggering it accidentally.

There's one corner case where it might still cause problems. Simply running isn't enough - XMir has to make progress through its event loop. That'll only happen if the X server is processing its wakeup events, and it's possible to effectively stall that by submitting a sufficiently awkward drawing request to the server. The X server will appear to freeze, and if the user then attempts to work out what's going on by switching to a VT and logging in, those input events will still be going to XMir. It's left as an exercise to the reader to construct ways to take advantage of this.

This can't happen in Xorg because the VT switch is blocked until the input devices have been released. Mir could have done the same, but doesn't because of a conscious design decision - in the Ubuntu Phone world, clients stop doing things when they're told to. Ubuntu Desktop is expected to behave the same way.

This is an unfortunate situation to be in. Ubuntu Desktop was told that they were switching to XMir, but Mir development seems to be driven primarily by the needs of Ubuntu Phone. XMir has to do things that no other Mir client will ever cope with, and unless Mir development takes that into account it's inevitably going to suffer breakage like this. Canonical management needs to resolve this if there's any hope of ever shipping XMir as the default desktop environment.


• It's still missing features

XMir doesn't support colour profiles. XRandR properties aren't exposed, so there's no way to control TV output encoding or overscan. There's still no hardware cursor support. Switching to XMir now would reduce functionality without providing any user-visible gain.

It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising. There's only one developer with previous X experience working on it full-time, and the announced schedule provided no opportunity to deal with unexpected problems. As if that weren't enough, there's obvious conflict between Ubuntu Desktop and Ubuntu Phone when it comes to developer time and required functionality. The one hardware vendor who's willing to take a public stand has demonstrated that they have no interest in supporting XMir, despite Canonical assuring people that they were already engaging in productive negotiations with GPU manufacturers.

Multiple monitor support may be the single most obvious feature where XMir is lacking, but it's not the only one. Technically and politically, this code is a long way from being ready for prime time. Without significant community contribution, Canonical need to focus on prioritising it appropriately rather than expecting a tiny number of developers to perform miracles. Or, alternatively, they could just drop XMir entirely and focus on Unity 8.

comments

I would probably not yet worthy of the admiration Emerson was alluding to but I do like to make things. As anyone who has read previous posts knows I have pretty much embraced the "do things, tell people" idea.

One small wrinkle is doing things needs somewhere to work. Since moving myself and the family to rented accommodation in Cambridge (swampy 3,500 year old English city, not the one in Massachusetts) I have been lacking space to do practical projects.

To fix this lack I have joined the cambridge makespace which, in addition to somewhere I can work gives me access to some tools I was previously unable to afford. The space gives practical training on the more complex machines (any tool can be dangerous if you do not use it correctly) which recently allowed my induction on the CNC router.

My instructor , Mark Mellors, who was good enough to give up some of his valuable making time to train me (and accidentally get his car stuck in a car park overnight by staying late) suggested that it was a good idea to have a design to try.

I decided to use this opportunity to actually create something useful (though now I re-read Marks message it did suggest a simple design...oopsy). I had been working at the electronics bench in previous weeks and been uncomfortable using the existing stools and chairs as they were either a bit high or unable to be adjusted high enough for the 80cm tall benches. I decided to design a 60cm tall stool for use at this workbench.

My initial idea was for a simple three leg stool, round top, three legs, how hard could it be? Initial research showed that showed that above 30cm the legs needed to be braced to each other. This is because the leg to seat joints simply cannot handle the stress caused by leverage which longer legs introduce.

I looked at the structure of several stools online and was initially drawn towards creating something like the IKEA Dalfred bar stool. It was discovered that the design would be easier to realise if it were made from sheet material which give a smaller challenge to a naive operator of a CNC router. Because of this simpler designs were researched and I eventually found a simple design I liked.

The design could not however be used directly as it was for imperial sized material which is not available in europe. I selected the QCAD open source CAD package and recaptured the design adjusting for the available 12mm plywood sheet material. This resulted in an imperial measurement design for metric materials.

Mark helped me transfer the DXF into the CAM software (vcarve pro 7, after I discovered the demo version of this software generates files which cannot be imported into the full edition!) and generate toolpaths for our machine. Once the toolpaths are saved to a USB stick (no modern conveniences like direct upload here) the job can be run on the machine.

Here I ran into reality, turns out that tolerances in imperial combined with lack of understanding how plywood reacts resulted in excessive play in the joints. This resulted in an unusable stool, which simply tried to rotate around its central axis and become flatpack. I had successfully turned 10 worth of plywood into some sawdust and a selection of useless shapes. On the other hand I did become competent with the router workflow so it was not a complete failure.

I was determined to make the design work so I decided to start from scratch with a similar design but entirely in metric. I performed some material research both online and practically (why yes i did spend an informative hour in several cambridge DIY shops with digital calipers, why do you ask?) it turns out that generally available 12mm thick plywood actually ranges between 11.9 and 12mm thick.

I did some test slot cuts of varying width and determined that the available stock can be "persuaded" to fit into a 11.8mm wide slot. This Interference fit joint is strong and removes the need for adhesive in most cases.

The sheet plywood material is readily available with a width of 1220mm and a height of 606mm (a full sheet is 2440mm long which is cut into four with a 4mm wide saw blade) so making the legs fit within a sheet and be close to the 60cm target should be possible.

I selected a suitable seat radius (175mm) and from that determined the minimal gap to the base ring with a 6mm end mill tool (20mm for two toolpaths and some separation) and hence the minimum suitable width of the base ring (50mm) giving a total radius of 245mm.

For the legs allowance was made for two joints of 30mm with 30mm separation between them the legs come out at 90mm width. If a 6mm space and a 6mm toolpath top and bottom of the sheet is accounted for a 582mm height (606 - 24) is available in which to fit the legs. The top of the leg which fits into the seat is 12mm tall leaving 570mm total leg height.

At this point I selected some arbitrary values for the leg positioning and angle (30mm from seat centre and 15 ) using a right angle triangle triganometry this produced a stool with a base of around 550mm or 100mm outside the radius of the seat. This seemed a pleasing shape and when the values for the holding ring were calculated it is at 104mm height which also seems to work out well.

This design was cut on the machine, lightly finished with some sandpaper and assembled. The legs slotted into the ring first and then the legs eased into the seat slots, the whole thing flipped and the seat hammered home onto the legs.

Success! It physically fit together and if you were brave enough you could sit on it. Unfortunately the plywood seemed to flex around the central axis of rotation in a rather alarming way, fine if you are under 70 kilos but not giving the impression of security most people want from their seating.

Ok, lets try with five legs instead of three (at least we can reuse the existing three legs)...nope still not good enough and another 10 gone.

The others in the space suggested a few ideas to improve matters and the one I selected was to use 18mm plywood instead of 12mm, this should improve rigidity. There was a brief pause in proceedings to discover 18mm sheet is actually 17.7mm and needs a 17.5mm slot to make the interference fit work.

A swift redesign later altering the seat radius, gap, ring width and leg height to accommodate the new material and we have version 4 and it works without caveat. Tested up to 150Kg load without trouble, there is a small amount of flex still but nothing that feels worrying.

I finished the stool by rounding the seat top edge with a ball bearing rounding bit in a manual router and applying a couple of coats of gloss acrylic varnish. Finished stool is now doing service at the space.

In conclusion the final design allows someone with a CNC router to create a useful 580mm high fixed stool for 7.50 in timber plus cutter wear and varnish so maybe 8.50 total.

You can actually get five legs and a seat/ring out of a 1220x606 sheet and with intelligent arrangement a single 1220x2440 sheet will probably yield five or possibly six stools in total

I am making the design files of the proven 18mm version available (heck they are all there...but you have been warned, none of the other solutions produce a satisfactory result) under the MIT licence so anyone can reproduce. More pretty pictures are also available.